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The present invention generally is directed to object orieated rntfK^ogjarTuriing systems. More, particularly, the 

t is (Srected to methods and means for irtte 
As set forth in U.S. Patent No. 5.499.365. full incorporated herett by reference, object oriented programming sys- 
tems and processes, also referred to as "object oriented confuting; enviitXTmerrts. - have been the subject of much 
investigation and interest As is well known to those haying sftoB in l|e art, object oriented programming systems are 
con po se d of a large number of "objects.* An object is a data structure, also referred to as a "frame," and a set of oper- 
ations or functions, also referred to as ~methode.~thrt 

of which contains an "attribute" of the data in the slot The attribute may be a primitive (such as an integer or string) or 
an object reference which is a pointer to another object Objects having identical data structures and common behavior 
can be grouped together into, and collectively identified as a "class." 

Each defined class of objects will usually be manifested in a number of "instances". Each instance contains the par- 
ticular data structure for a particular example of the object In an otajpct oriented computing environment, the data is 
processed by requesting an object to perform one of its methods by sending the object a "message". The receiving 
object responds to the message by choosing the method that mnplereents the message name, executing this method 
on the named instance, and returning control to the calling high level routine along with the results of the method. The 
relationships between classes, objects and instances tradhfonaUy have been established during "build time" or genera- 
tor of the object oriented computing environment. La, prior to "run time" or execution of the object oriented computing i 
Environment ■ M 

\ In adoption to the relationships between dosses, objects and instances identified above, inheritance relationships I 
also exist between two or ny a rtasTor such that a first class may be considered a "parent" of a second class and the 1 
second class may be considered a "child" of the first class, bi other words, the first class is an ancestor of the second I 
class and the second class Is a descendant of the first class, such that the second class (1 &. the descendant) is said \ 
to inherit from the first class (La. the ancestor). The data structure of the child class includes ail of the attrfcutes of the < 



nhertt from the first class (La. the ancestor)' The data structure of the child class includes « 
entdass* - 



1 



Object oriented systems have heretofore recognized "versions" of objects. A version of an object is the same data 
► the object at a different point in time For example; an object which relates to a "work in progress", is a separate ver- 
i of the same object data which relates to a cornpkrted and approved work. Many applications also require historical 

► of data as it existed at various points in time. Thus, offferent vjsrsione of an object are required. 
Two articles providing further general background are E.W, Dijkstra, The Structure of "THE" Multi programming 
Owminicabons of the ACM. Vol. 11. No. 5. May 196a pp. $41-348, and C.A.R. Hoare, Monitors: Operating 
t Structuring Concepts. Communicationeof the ACM, VoL 17, Na 10, October, 1974, pp. 549-557, both of which 
(re incorporated herein by reference The earlier article describes methods for synchronizing using primitives and 
plains the use of semaphores while the latter article develops Brlnch-Hansen's concept of a monitor as a method of 
Structuring an operating system. In particular, the Hoare article irtit)duces a tomi of synchronic 
{escribes a possible method of impiementation in terms of semaphores and gives a proof rule as well as illustrative 
example^ 

As set forth in the Hoare article, a primary aim of an operating system is to share a computer installation among 
many programs making unpredictable demands upon its resources. A primary task of the designer is, therefore, to 
Resign a resource allocation with scheduling algor i t hms for resources of various kinds (for example, main store, drum 
; t^e harriers, consoles). In order to simplify this task, the programmer tries to construct separate 
>for each class of resources. Each scheduler then consist^ of a certain amount of local administrative data, 
i some procedures and functions which are called by programs wishing to acquire and rel ease resources. 
> of associated data and procedures is known as a monitor. 

i communication environment (ACE) is an object-oriented type of network programming system devel - 
oped by Douglas C. Schmidt, an Assistant P rofe ssor with the Department of Computer Science, School of Engineering 
and Applied Science, Washington University. ACE encapeulatee user level units and WIN32 (Windows NT and Win- 
dows 96) OS mechanisms via type-secured, efficient and object-orieipted interfaces: 




- Internet-domain and UNIX-domain 



TU, Named pipes (for UNIX and; Win 32) and 



decreets on Win 32; 



aexing - via selectQ end podO on UNIX and WattRrtfeffiple 
i threads. POSIX Pthreads. and Wlrr32 threads; | 

t dynamic linking facilities - ag., oioperitfsymtitctose on UNIX and LoadLibrary/aetProc on Win 32; 
/-mapped files; f 

I 
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System VIPC - shared memory, semaphores* message queues: and 
Sun RPC (GNUrpc4-+). 
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In addition. ACE contains a number of higher-level class categories and network programming frameworks to inte- 
grate and enhance the lower«4evBl C++ wrappers. The higher-level components in ACE support the dynamic configura- 
tion of concurrent network daemons composed of application services. ACE is currently being usqd in a number of 
commercial product? including ATM signaling eomvare products, PBX monitoring applica t ions, network management 
and general gateway communication for mobile communications systems and enterprise-wide distributed medical sys- 
tems. A wealth of irAnr ub on and documentation regaiding ACE is available on the worldwide web a* the following urti- 
versai resource Iocmt: 

http»VAvwwxZwus1J.eoW» ' 

The following aweviations are or may be utilized in Ms application: 



Thread - a 
of 

through a 
SrhctifQftegBi 



execution unit within a process. A monitor synchronizes, by forced sequentiaBzatfon, the parallel 
simultaneously running Threads, which all call up funct io n s of one object that are protected 

a means of the operating system for reciprocal justification of parallel activities, 
itrve for parallel activities. 




Mutex - a speqfl Synohronizaiions-Prirnitive for parallel activities, for mutual exclusion purposes, it includes a crit- 
ical code i 

- an event waiting queue for parallel activities referring to a certain condition. 
f^Qi - a A*ax ol the monitor for each entry-function, for protection of an object for allowing only one parallel 
activity a time to us? an Entry-Routine of the object 

- longtime delay of one parallel activity within a condition queue or event waiting queue for 



acronym s are or may be used herein : 

xmjs Function Manager 
Event Synchronous Asynchronous Manager 

Area Logic 
Programmers Interface j. 
language 

Transport Optimizing observer-pattqrrMifcB system supporting several Modes (client/server - 
for an IDL-less Communication subsystem (This is the subject of commonly assigned and 
application. Attorney Docket No. GR ?6 P 3108 E) - <; 

Representation 

. i ' 

Coirvruinication 

e Architecture (a Siemens AG cortputing system conven^on) 




I 



of software mo dule s or building blocks has been hard cod ed in an application program inter- 
linkable into a process, but was not location transparent Additionally, the interface has 
of an interface definition language (IDL) with hard coded objec( references. 



The present invention provides a method and/or means for cantoning independent semantic-less software mod- 
ules or building blocks Into large appOcafiona wimoU changing any o 

arty adapters. Tfc that end. the functionality of a module or building block is fully separated from the surrounding envi- 
ronment so thatft need not be located wItMn the same proosss* and can instead to 
the need of an interface definition language. 

In an embodiment the invention provides a method for designing software modules comprising the steps of: 



defining input Bd output 



that are fully 
linkable, semantic-free 



modules by input and output connections points; 
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providing autoroutod pattern based fully oistributsble 




on an event comrnunicHtmn framework. 



conjputfng system, comprising objects with seeianti* 
framework providing automated, pqttern- 



tn an ernbodiment the invention prov id e s an 
class, dynamically linkable inputs and outputs; and 
fused, fully alstnbutable events. * I f 

In an ernbodiment, the inputs and outputs of the objects me provided by linte to CsaConnectable and Csa Remote 

, r esp oca vely. I [ 

In ao ambodimant each data atructura associated with the inpu^ft and outputa is daaortbad in a separata haadar 
^le whicfr can be used by every object to be linked. 

In af entrapment each object is a shared library which is dynaraicafly tintable at runtime by an ASCII configura- 
i filing names of the inputs and outputs of the objects. - 

These and other features of the invention are discussed in greater detail below in the following detailed description 
f the presently preferred embodiments with reference to the accompanying drawings. 

gSCRIPTION OF THE DRAWINGS 
re 1 illustrates a comparison of haroWare and software ICs 
figure 2 illustrates a application utilizing software ICs. 
figure 3 illustrates a comparison of hardware RMjs and software RALs. 

>FNipiMQ APPLICATION? 

The following commonly assigned copending a p pli cat ions are incorporated herein by reference: 



1 Title 


Application NUMBER 


Filing Date 


Attorney; Docket fJa 


IMONrrpR SYSTEM FOR SYNCHRONIZATION 
■ OF TH^EAT^S WITHIN A SINGLE PROCESS 

[SERVICE A^D EVENT SYlvCHRONOUS/ASYN- 
ICHROjjOU^ MANAGER 

1 ASYNQHROfvOUS TRANSPORT OPTIMIZING 
iOBSEdft/ER-PATTE RN LIKE SYSTEM SUPPORT- 
I ING SEVERAL MODES FOR AN INTERFACE 
■DEFINITION LANGUAGE-LESS COMMUNICA- 
1 TION SUBSYSTEM 




1 


GR96|P3106^ 
GR96|P3107E 
GR9&P3108E 



30A 



^ ^DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS 

As set forth above, the present invention provides an approach for combining independent semantic-less building 
I blocks into larger applications/without changing any code within the budding blocks and without writing any adapters. 
A i The result is a system or architecture wherein software biocte can be combined in the same manner that integrated 
V ^circuris are combinabla 1 

' For the purposes of this invention, the way a software building block connects to its outside environment (which 
/nay consist of one or more other building blocks as wall as user written code) is via CsaConnectable (supplier} and 
CsaRemote (consumer) objects/classes, regardless whether the othef endpoint of the connection resides in the same 
sa process or on a remote host (with optimization, if local). This rule is applied to all building blocks. For further imorrnation 
f regarding the CsaConnectable and CsaRemote objectsfc1asce6» reference should be made to the commonly assigned 
I and copending applications incorporated by reference above, and in particular Attorney Docket Nos. GR 96 P 3107 E 
V*fand GR 96 P 3108 E, respec%ely. 

Each data structure associated with the irtputs and outputs otthebuik^ 
> which can be used by evejy build ng blockthatistDbeoonnecteoj 
Each buikJingblocki&reaAzedorconsm 

figuration file as is used in public domain ooirmurttcation parking The names of the inputs and outputs are 
I during dynamic linking and this allows changing the configuration without any recompilation or relinking. 



The great advantage of this approach is that a flfx&e and rdgh level pattern arises from the optimal combination 
of other simple, well designed, and sernantic-<e6S pattern s . Agaip, this mechanism is very similar to combining inte- 
grated circuits on boards in the hardware world. J j 

Figure t is useful for comparing the sirrntarities betwoon hardware integrated circuits (IPs) and th4 present software 
object*. In Figure 1 . a hardware IC HIC has two input pins 11 and 12 and two output pins 01 and Q2. Similarly, the soft- 
ware object SIC has two inputs Ri and R2 via CsaRprtote and two outputs C1 and C2 via CfeaCorinjpctable. 

An example of coding for i n^ l e ment in g such a efftware *C system fol lows: 



817 016 ^2 



INPUT/OUTPUT CLASS DECLARATIONS 



#ifndef SAMPLBCLASSXH 
#de£ine SAMPLBCUVSS1H 



* Input/Output data structure * 



\******************* 

struct Sampled as si { 

int thelnteger; 
DECLARE_MS C ( Satnpl eClas si ) 

>, , ... t 

IMPLBMEOTV MSC (SampleClassl , V( thelnteger ) ) 
#endif / / SAMPLE CLASS 1H 
#±£ndef SAMPLBCLASS2H 
#define SAMPLBCLASS2H 

*" " ! * • - 

* Input /Output data structure * 

struct SarapleClass2 { 
int thelnteger; 
DECLARE_MSC (Sampled ass?) 

}; • ' ' ' . ■ . 

IMPLEMENTJWSC (SarapleClass? / V(tbelnteger) ) 
#endif / / SAMPLBCLASSXH 



I 
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II. BUILDING BLOCK HEADER FILE 

<ace/Service_Ob j ect . h> 
<CsaConnectable . hh> 
<CsaReroote . Hh> 
<SainpleClas6l . li> 
<SampleClass2 .n> 



class SampleApplication 
{ 



public ACE_Service_ Object 



public: 

virtual int init (int, char**) ; 
virtual int f ini (void) / 

virtual int info (cbar** f | size_t) const; 
SampleApplication (void) 
- SampleApplication (voidD ; 
brocected: 

I CsaCoxinectable <SarapleClajssl> * output l; 
I CsaConnectable <Sanq?leClaps2> *output2; 
I CsaRemote <SampleClasel> p input 1; 
I CsaRemote <SarapleClaes2> {* input 2; 



#endif/ / 



SAMPLE APPLICATION 
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III. BUILDING BLOCK IMPLEMENTATION 

#include<CsaConnectable . hh> 
# include <CsaRemote . Mi> 
#include<SampleApplication . h> 

int SampleApplication : : init(int argc, char **argv) { 
cout « endl << •Initial! zing " « endl; 
input 1 - new CaaRemote <SanplfClassl> (argv[l] ) ; 
input2 m new CsaRetnote < Sampled as s2> (argv[2]); 
output 1 = new CsaConnectable <SampleClassl> (argv[3l); 
output2 o new CsaConnectable <SainpleClass2> (argv[4]) # - 
return (0) ; 

} 

int SampleApplication : : fini (vodd) { 

cout << endl « "Finalizing ° « endl << endl; 

delete input 1; 

delete input 2; 

delete outputl; 

delete input 1; 

return (0) ; 

} 

int SampleApplication : : info (chair**, unsigned) const { 
cout << endl « "Returning infos about ■ « endl; 
return (0) ; 

} 

SampleAppliction : : SainpleApplictaion<void) {} 

SampleApplication ; : -SampleApplication (void) {} 

/* Dynamically linked functions used to control configuration 

I extern n C n ACE_Service_Object *_a3-loc (void) ; 
ACE_Service_Object *_alloc (voidO { 

return (ACT_Service_Object * ) new SampleApplication,- 
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IV. ASCII CONFIGURATION FILE 
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static SVC_Manager tt -d -p 3333 M 

dynamic SarapleApplicatxon j 

! 

ACB_Service_Ot>j ect * . /SampleApp^ication . so : _alloc ( ) ; 
"SampleApplication inl_name in2 _|iame outljame out2_jname" ^ 
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J In Figure 2 there is illustrated in block diagram form a possible implementation of software ICs in a system with 
fore than on© application. In Figure 2 there are illustrated five rnflw^Q ICs: IC1, IC2. IC3, IG4 and IC5. Addrtionally. 
ttere are two applications, Application 1 and Application 2. errployinqihe software ICs. Application 1 contains software 
£6 IC1. IC2 and IC3. while Application 2 contains software ICs IC4 and IC& As can be seen. Application 1 and Appo- 
rtion 2 interact with each other, as well as externally of the process Of system containing Application 1 and Application 
£ via inputs and outputs of the software ICs. 

As illustrated. IC1 has two inputs C11 and CI 2. IC1 also has one output via R11. The inputs 01 1 and C12 are con- 
nected to two outputs of IC2. R21 and R22, respectively. An input C21 of IC2 ie connected to the output R1 1 of IC1. 
IC3 has an output R31 connected to the input C22 of IC2, and input C31 connected externally of the process corv 
i the applications, an input C32 connected to an output R41 of IQ4 and an output R^2 connected to an input C52 



j IC3 
pining 1 




externally of the system 

ed externally of the proc- 

Moreover, the data are auto- 
configuralion and interaction 

from ACE. to obtain a very 
power of eynchronoue behavior 



of IC5 and externally of the system In adoption to output R41 , IC4 has a input C41 
and an output R42 connected to an input C61 of the ICS. ICS also has an output 
ess or system containing the applications. 

The inputs and output are via CsaConnectabie and CGaRemote as descrtoed 
fDUed to the various inpirts and outputs via d 

Tthe applications without requiring recompilation or relinking. 
In addition, the foregoing software IC principles can be uunijfnecf with a 
powerful eoftware building block that behaves like a hardware PAU afd that offers 
jwthin the building block and asynchronous behavior/Interaction outcido 

of the building block. The internal processing rate (the counterpart to a clock rate in a hardware PAL) is thus fully 
^dependent from the event inpuVoutput rate of the connected e nva ^nm o n t The necessary buffering to achieve the 
conization is also provided without concern to semantics. Sirrilqr to hardware PAL synchronization solutions, the 
ironization task can be configured into a software PAL as noodad. 
Figure 3 illustrates a comparison between hardware PALs and SqRware PALs. As illustrated, a hardware PAL 310. 
> a hardware IC, can have two input pins 11 and 12 and two output pais Ol andQ2. However, within the hardware PAL 
P0 there also are provided registers/buffers reg in which incoming and outgoing data or signals are stored. 

The counterpart software PAL 312 has inputs R1 and R2 and outputs C1 and C2 like the software IC descrfred pre- 
^ously. However, also illustrated are tasks T1 and T2 that replace the feojstersAjuffers reg of the hardware PAL 310. In 

rr respects, the software PAL is similar to a software IC. as des cr ibed above. 
A software PAL provides inner lope flexibility to a softiMare IC by means of active object support Incoming events 
fre able 1 > be buffered by tasks, such as the task T1, before fiirtr^ processing by the inner logic. Further, outgoing 
events 04 i be taken from a buffer, such as the task T2. thereby decoupli ng the events from the inner I ogic of the soft- 
ware PAl 

Attho gh rnoctf ications and changes may be suggested by those skilled In the art It is the Intention of the inventors 
|o emboc r within the patent warranted hereon all c ha nge s and rnoriacations as reasonably and p roperly come within 
Jiescopi pi their contribution to the art - 

Claims 




1 

\ 



An a ject oriented computing system on a computer platform, comprising: 
< bjecte wrth semantidesa dyran^ 

i n event ccmriiinicaiJon framework provkJng automated, papern-based. fully dtetrfcutable events. 



The 



oriented computing system according to ctatm 1 , whatein the inputs anjl outputs of the objects are pro- 
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vided via CsaCmtectable and CsaRemoteob|ects. respectively. 

a. The object oriented computing system according to claim 2. wherein each date structure associated with tfte inputs 
and outputs is ascribed in a separate header fie whig* can be used by every object to be unkad. 

4. The object oriat^ed confuting system acccccfng to d^m 2 or 3. wherein each object is a shared tibrary which is 
dynamically linkable at runtime by an ASCII configuration filing names of the inputs and outputs of the objects. 

5b An object oriented competing system on a computing system, comprising objects having dynamically linkable 
inputs and outpyts and internal tasks for queuing of data transferred into and out from the objects via said inputs 
and outputs, re^>ective*y; and an event communication framework providing automated, pattern-based, fully die- 
tfft&jtabie* 



uts, rmmodbpty; 
» event* 



6. The object orienpd computing system according to claim 5, wherein the Inputs and outputs of the objects are pro- 
vided via CsaCdpnertahte and CsaRemote objects, respectively. 

7. The object oriented computing system according to claifn 6, wherein each data structure associated with the inputs 
and outputs is described in a separate header fie whicj^ can be used by every object to be linked. 

ft. The object oriented computing system accordmg to dqpm 6 or 7, wherein each object is a shared Iferary which is 
dynamically linkable^ runtime by an ASCII configuration file containing names of the inputs and outputs of the 



9. A method tor designing software modUee In an object oriented computing system, comprising the steps of: 

defining inplt and output events that are fuUy tfstn^utabie; 

configuring dynamic linkable. s emanfo *ee suftw^ e modules by input and output connections points: 
providing aifonxjfpd pattern based fully otistrtoutat^e events based on an event comrmriicatJon framework. 

v ? j 

10. A storage modu^m including object oriented code havinp an object oriented computing syrtem on a computer plat- 
form, compnsintt: 



objects wnhjsemanttcieGS. dynamically linkable inputs and outputs; and 

an event communication framework proviclng autornated. pattern-based. fUly distributable events. 

11. The storage rnefcmi acc ordin g to claim 10. wherein th» inputs and outputs of the obj 
i stable and riAneuw He objects* respectively* 

12. The storage me0um aocording to claim 1 1 , wherein each data structure associated wit!} the inputs and outputs is 
described in a separate header fie which can be used^y every object to be linked. 

13. Tte storage rnetfumaccoroln^ to 

able at runtime by an ASCII configuration filing names of the Inputs and outputs of the objects. 

14. A storage medium incfrKling object oriented code for an object oriented computing system on a computing system, 
comprising objects having dynamically linkable iripute and outputs and imerrtal taste tor queuing^ 

ujtfo and out fronf the objects via said inputs and output* respectively; and €m 
wjding automaft^ pottom-b^ 

1&. The storage medium according to claim 1 4, wherein the inputs and outputs of the objects are provided via CeaCon- 
qpctable and CnRemote objects, respectively. 

16. TJie storage medium according to claim 15. wherein etich data structure assnriatPrt with the inputs and outputs is 
described in a separate header fie which can be usedpy every abject to be (inked. 

17. The storage medium according to claim 15 or 16, when|in each object is a shared lixary which is dynamically link- 
able at runtime by cut ASCII configuratkmftlecortfttnin^ names of the inputs and outputs of the objects. 



* 

t 



EP0 817016 A2 



18. A storage medium including object oriented oodelbramethodtordeslgntng software modUes ft 
computing system, comprising the steps of: 

defining Input and output events that are fuBy dtetrfbulaMe; 
I configuring dynamic linkable, semantic-free software modules by input and output connections points; 

' providing autorouted pattern based fuDy distributable events based on an event communication framework. 
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